Description

GetPodMetadata in the podgroupcontroller called FetchPodResourceClaims unconditionally on every reconcile, including for pods in Succeeded/Failed phases. The DRA driver removes per-pod ResourceClaim objects as soon as a pod reaches a terminal phase (independent of pod deletion), so the lookup always failed with NotFound and produced spurious ERROR logs on every reconcile cycle until the pod object itself was eventually cleaned up — which can take an indefinite amount of time when Job.spec.ttlSecondsAfterFinished is unset.

ERROR  Failed to calculate metadata for pod <ns>/<pod>
{"error": "failed to get resource claim <ns>/<claim> for pod <ns>/<pod>: ResourceClaim.resource.k8s.io \"<claim>\" not found"}

The fix adds a phase guard at the top of GetPodMetadata. Terminal pods skip the ResourceClaim lookup and return empty RequestedResources/AllocatedResources — which is what the existing isActivePod/isAllocatedPod guards downstream would have produced anyway.

This is the same root cause as #1455 (fixed scheduler-side in #1456), but the podgroupcontroller metadata path was missed at the time.

Related Issues

Fixes #1529

Checklist

• Self-reviewed
• Added/updated tests (if needed)
• Updated documentation (if needed)

Breaking Changes

None.

Additional Notes

Tests

• TestIsTerminalPod — table-driven check across the four phases, matching the style of the existing TestIsActivePod/TestIsPodAllocated.
• TestGetPodMetadata_TerminalPodSkipsResourceClaimLookup — integration-style test with a fake.ClientBuilder and a Succeeded/Failed pod referencing a missing ResourceClaim. Verified to fail (nil-deref panic from FetchPodResourceClaims) without the fix and pass with it.

Validation

• go test ./pkg/podgroupcontroller/... ✅
• go vet ./pkg/podgroupcontroller/... ✅
• gofmt -l pkg/podgroupcontroller/controllers/metadata/ clean